In general, I'd avoid using panick to handle problems, rather returning results, and I'd think about how the data should move.

The latter might be a follow-up thing to optimize this, though, since you said this is supposed to be a one-on-one rewrite from the java code.

A lot of the speed in rust code is caused by thinking about data flow. How to avoid copies/clones, trying to use move semantics as much as possible...

I mostly follow @ninewise's remarks: using better error handling with Result's will improve readability of the code. You want to search for everywhere where you:

• do a match on a Result or Option,
• do an unwrap or expect,
• do an eprinln followed by an exit.

Quick review, don't have much time. I can probably do a bigger one only in the weekend or somewhere next week, so don't wait for my explicit approve to merge.

There error handling is now way cleaner 👍

There are a few locations where the program would now continue while something fatally wrong has happened (e.g. not being able to write to a file). The program would then spew out lots of error messages without doing anything meaningful. I think in those cases, that should become a fatal error stopping the program.